07. CDN

📝 Contents

CDN을 사용하는 이유

  • CDN은 웹 캐시 서버들을 전 세계에 분산 배치하고 원본 서버의 콘텐츠들을 웹 캐시 서버에 캐시해 사용자들에게 서비스함으로써 사용자가 기기나 브라우저가 웹 콘텐츠를 보다 빠르게 다운로드할 수 있도록 하는 기술임
  • 국내에 데이터 센터를 둔 서비스가 해외 시장에 진출하려 할 때, 서버 용량과 로딩 속도를 생각해야 함
  • 서버 용량을 증설하면 기존 아키텍처를 크게 변경하지 않을 수 있지만, 비용이 들고 해외 사용자들과 지리적 위치가 멀기 때문에 로딩 속도를 보장하기 어려움
  • 해외에 직접 데이터 센터를 구축하면 막대한 예산을 투입해야 하고, 기존 애플리케이션과 동기화하려면 복잡한 아키텍처를 설계해야 함
  • 해외에 있는 호스팅 서비스를 이용하면 비용을 많이 절감할 수 있지만, 원본 애플리케이션의 수정, 테스트 및 배포에 대한 계획을 꼼꼼하게 세워야 하며 동기화 이슈도 여전히 남아 있음

  • CDN을 사용하면 다음과 같은 이점이 있음

  • 성능 및 안정성 보장

  • 아키텍처 단순화

  • 높은 비즈니스 투자 수익

  • CDN의 특징은 다음과 같음

    • 동적 콘텐츠 가속
    • 프런트엔드 최적화
    • 동영상 또는 라이브 스트리밍 서비스
    • 클라우드 보안

CDN의 원리

  • CDN 업체들은 대부분 사용자 스스로 CDN 설정을 수정하고 관리하도록 권장함
  • CDN의 기본 아키텍처와 동작 원리를 잘 이해한다면 스스로 CDN을 설정하고 관리하는 데 큰 도움이 될 것임

CDN 서비스 아키텍처

  • CDN은 원본 서버와 최종 사용자들 사이에서 리버스 프록시 서버 형태로 존재함
  • 네트워크의 끝단, 사용자와 가장 가까운 곳에 위치한 이러한 서버들을 엣지 서버라고 부르면 CDN 업체들은 전 세계에 또는 특정 지역에 여러 개의 POP을 만들어 엣지 노드들을 구성함
  • CDN 업체마다 자체 네트워크를 구축하는 방법에 차이가 있음
  • 세계 주요 도시에 데이터 센터들을 구축하고 이를 중심으로 POP들을 구성하거나, 자체적인 데이터 센터 없이 주요 ISP 데이터 센터나 POP 내 서버들을 임대하여 사용하는 경우도 있음
  • 어느 쪽을 사용하든 사용자에게 빠르고 안정적인 서비스를 제공하려면 가능한 많은 위치에 많은 수의 엣지 노드가 필요함

CDN 동작 방법

  • 사용자가 어떤 웹 사이트에 접속하기 위해 브라우저 주소창에 URL을 입력하면 브라우저는 가장 먼저 DNS로부터 웹 사이트의 IP 주소를 조회함
  • 그리고 최종적으로 웹 사이트를 호스팅하는 조직의 DNS 서버가 도메인명에 대한 IP 주소를 반환함
  • 그 후 브라우저는 그 IP 주소로 웹 콘텐츠를 요청함
  • 만약 사용자가 웹 사이트 호스팅 서버와 지리적으로 먼 곳에 있다면 요청이 서버에 도착해 응답이 올 때까지의 시간(RTT)이 오래 걸림


  • 반면 CDN을 사용하면 브라우저가 웹 사이트 IP 주소를 조회할 때 호스팅 조직의 DNS 서버는 자사 서버의 IP 대신 CDN 서비스 제공자의 도메인명을 반환함
  • 이 경우 사용자 브라우저는 CDN 서비스 제공자의 DNS 서버에 해당 도메인명에 대한 IP를 다시 요청하고 CDN 업체의 DNS 서버는 사용자와 가장 가까이 위치한 엣지 서버의 IP를 최종 반환함
  • 엣지 서버의 IP를 받은 브라우저는 사용자 요청을 그 엣지 서버로 보냄
  • 엣지 서버는 캐시된 콘텐츠를 사용자에게 빠르게 반환하거나 캐시되어 있지 않은 경우 원본 서버에서 콘텐츠를 받아와서 캐시한 후 브라우저에 응답함

CDN 적용 방법

  • CDN을 적용할 때 직접 소스 코드를 수정하지 않고 DNS만 변경하면 됨

  • 일반적으로 CDN 서비스를 사용하려면 다음과 같은 절차를 거침

  • 원본 서버로 사용할 호스트명과 IP를 네임 서버의 A 레코드로 추가함

  • CDN 설정에 원본 서버의 호스트명으로 org-www.example.com을 등록함

  • 마지막으로 기존 도메인명에 부여되어 있던 IP 정보를 CDN 서비스 제공자의 도메인명으로 변경해야 함

  • 쉬운 설명을 위해 원본 서버명을 org-www.example.com으로 예를 들었지만, DDoS 같은 악의적 공격의 표적이 되지 않기 위해 기존 서버명의 해시값을 사용하는 등 공격자들이 쉽게 예측할 수 없는 도메인명 사용을 권장함

댜중 캐시 전략

  • 다중 캐시란 사용자와 서버 사이에 여러 개의 캐시 계층을 주어 캐시 효율을 극대화하는 기술임

캐시 축출

  • 용량이 일정 한계치에 도달하면 캐시된 콘텐츠에 우선순위를 부여해 낮은 순위의 콘텐츠부터 삭제하는데 이를 캐시 축출이라고 함

  • CDN 서비스 제공 업체에 따라 우선순위를 부여하는 정책이 다르겠지만 공통적으로 아래와 같은 사항들이 적용됨

  • 일정 기간 캐시 적중이 없었던 콘텐츠

  • 캐시 적중률이 미미한 콘텐츠

  • 더 오래된 콘텐츠

  • 만약 캐시 서버 사용량이 임계치에 도달하면 규칙에 의해 정해진 우선순위에 따라 낮은 순위의 콘텐츠를 삭제하고 새로운 콘텐츠를 캐시함

롱테일 콘텐츠

  • 특정 콘텐츠가 캐시에서 축출되는 주 요인은 물리적 한계뿐만 아니라 그 콘텐츠의 캐시 적중률이 매우 낮기 때문임
  • 생성 초기 많이 조회되다가 짧은 시간이 흐른 후 조회 수가 확 줄고 이후 거의 조회되지 않는 콘텐츠를 롱테일 콘텐츠라고 함
  • 롱테일 콘텐츠는 웹 사이트 내 콘텐츠 종류가 많을수록 그리고 사용자층이 여러 국가에 넓게 퍼져 있을수록 심화됨

캐시 서버 간 캐시 콘텐츠 공유

  • 사용자가 많더라도 사용자층이 여러 국가에 넓게 퍼져 있으면, 콘텐츠는 모든 국가나 주요 도시마다 설치되어 있는 수많은 엣지 서버에 캐시되어 있을 것이기 때문에 하나의 엣지 서버를 기준으로 실제 사용자 방문에 의한 캐시 적중률은 매우 낮음
  • 캐시된 콘텐츠가 전 세계에 분산된 엣지 서버들 사이에서 마치 하나의 서버를 사용하는 것처럼 공유될 수 있다면 아무리 널리 퍼져 있다 해도 해당 콘텐츠의 캐시 적중률이 높아질 것임
  • 이러한 엣지 서버 간 캐시 공유는 ICP(Internet Cache Protocol)와 같은 특별한 프로토콜을 사용해 빠르게 이루어져야함
  • 따라서 동일한 백본 네트워크에 연결된 서버 사이에서만 이루어짐
  • 일반적으로 동일한 POP 서버들은 캐시된 콘텐츠를 서로 공유할 수 있음

다중 계층 캐시

  • 전 세계에 흩어져 있는 캐시 콘텐츠들을 공유하기 위해 다중 계층 캐시 전략을 사용할 수 있음
  • 다중 계층 캐시란 엣지 서버들과 원본 서버 사이에 추가 캐시 서버 계층(부모 계층)을 두어 같은 콘텐츠를 여러 번 캐시하는 방식임
  • 추가 캐시 계층을 통한 공유 효과를 얻으려면 다음 조건을 만족해야 함
  • 첫째, 부모 계층은 원본 서버에 가까이 존재해야 함
  • 둘째, 부모 계층의 캐시 서버 수가 자식 계층의 캐시 서버 수보다 훨씬 적어야 함
  • 위 조건들을 만족했을 때 다중 계층 캐시를 사용한다면 다음과 같은 효과를 얻을 수 있음
캐시 적중률 향상
  • 자식 계층의 캐시 서버들은 부모 계층의 캐시 서버들을 사용해 콘텐츠를 공유할 수 있음
  • 최초로 콘텐츠 요청을 받은 엣지 서버가 그 요청을 부모 계층의 엣지 서버에 전달함
  • 그리고 부모 계층의 엣지 서버가 원본 서버에서 콘텐츠를 응답받아 캐시한 후 자신을 호출한 엣지 서버에 다시 전달함
  • 이렇게 부모 계층의 엣지 서버에 콘텐츠가 캐시되면 자식 계층의 나머지 엣지 서버들은 원본 서버에 콘텐츠를 요청할 필요 없이 부모 계층에서 캐시된 콘텐츠를 받아 서비스함
  • 이렇게 함으로써 부모 계층 캐시 서버들의 캐시 적중률이 높아지고, 이에 따라 캐시된 콘텐츠가 캐시 서버에서 축출될 확률도 낮아짐
과도한 트래픽으로부터 원본 서버 보호
  • CDN 업체가 제공하는 POP 수가 적을수록 원본 서버의 캐시 트래픽은 줄지만 사용자에게 응답하는 속도가 느려짐
  • 반면 POP 수가 많을수록 원본 서버의 트래픽은 늘어나지만 사용자에게 응답하는 속도는 빨라짐
  • 후자의 경우 다중 계층 캐시를 사용하면 사용자의 응답 속도를 떨어뜨리지 않으면서 원본 서버로의 트래픽을 획기적으로 줄일 수 있음
사용자 요청에 대한 응답 속도 향상
  • 다중 계증 캐시를 사용하면 자식과 부모 엣지 서버 사이에 전달 경로 최적화가 적용되므로 사용자 요청에 더 빠르게 응답할 수 있음

전달 경로 최적화

  • 전달 경로 최적화는 애플리케이션 응답 속도를 빠르게 하는 중요한 기능임
  • API 호출 같은 동적 데이터뿐만 아니라 캐시가 만료된 콘텐츠를 원본에서 다시 불러올 때도 필요한 기능임
  • 전달 경로를 최적화 할 때 경로를 라스트 마일, 미들 마일, 퍼스트 마일 세 구간으로 나눌 수 있음
    • 라스트 마일: 최종 사용자와 CDN 엣지 서버 간 구간
    • 미들 마일: CDN 네트워크 구간
    • 퍼스트 마일: 엣지 서버와 원본 서버와의 구간

라스트 마일 최적화

  • 라스트 마일 구간의 경로 최적화는 최종 사용자 요청을 사용자와 가장 가까운 곳에 있는 엣지 서버로 전송하는 일임
  • CDN에서 일반적으로 사용하는 가장 가까운 엣지 서버 선택 방법은 크게 두 가지로 나눌 수 있음
DNS 기반 엣지 선택
  • DNS 쿼리에는 사용자 기기의 IP 정보가 포함되지 않아 실제 사용자 위치를 정확히 알 수 없지만, 사용자의 로컬 DNS IP 정보는 DNS 쿼리에 포함되어 있어 이를 활용해 사용자의 위치 정보를 짐작할 수 있음
  • 자신이 사용하지 않는 DNS 정보를 미리 지정하지 않는 한 가입된 인터넷 제공 업체(ISP)에서 제공하는 DNS가 자동으로 사용됨
  • 또한 사용자와 가장 가까운 DNS 서버가 배정되도록 최적화되어 있음
  • DNS 프로토콜은 매우 기본적이고 안정적으로 사용되기 때문에 DNS 기반 엣지 선택 방안도 안정적으로 운영됨
  • CDN 제공자의 의해 모든 엣지 서버들의 상태가 자세히 모니터링되므로 사용자 요청이 있을 시 최선의 엣지 서버가 선택될 확률이 높음
  • 하지만 사용자 위치 정보가 실사용자의 아이피 정보가 아닌 인터넷 서비스 제공자의 DNS 서버 위치 정보이므로 사용자가 특정 DNS 서버를 지정해 사용하는 경우 엉뚱한 곳의 엣지 서버가 선택될 수 있음
애니캐스트 기반의 엣지 선택
  • 네트워크에서 데이터를 전송하는 여러 방식 중 유니캐스트 방식을 흔하게 사용함
    • 유니캐스트: 보내는 측과 받는 측이 1:1로 통신하는 방식으로써 보내는 측은 받는 측 주소를 정확히 알고 메시지를 전송해야 함
  • 클러스터 환경에서 관리 노드가 자식 노드들을 관리할 떄 멀티캐스트 방식을 흔히 사용함
    • 멀티캐스트: 1:N 통신 방식으로 보내는 측은 받은 노드들의 그룹 주소 또는 포트를 알고 있어야 함
  • 브로드캐스트는 불특정 다수에게 메시지를 전송하는 방식으로 메시지를 받을지 말지는 전적으로 수신자가 결정함


  • 애니케스트 역시 네트워크 상에서 원하는 IP 주소로 데이터를 전송하는 방식 중 하나임
  • 애니캐스트도 1:1 전송 방식이지만 유니캐스트와는 다르게 다수 노드가 같은 IP 주소를 가짐
  • 그리고 보내는 측이 그 IP 주소로 메시지를 보낼 때 네트워크상 가장 가까운 노드를 선택해 전송하는 방식임
  • 보내는 측의 라우터와 경계 프로토콜에 의해 전송될 노드가 결정되는 것임


  • 애니캐스트 기반 엣지 선택 방식에서 CDN 제공자는 모든 엣지에 동일 IP를 부여하거나 또는 지역별 클러스트를 만들어 클러스트마다 다른 IP를 부여하기도 함
  • 사용자 브라우저가 웹 사이트의 도메인명에 대한 IP 정보를 요청하면 최종적으로 CDN의 DNS 서버가 사용자에게 가장 가까운 지역의 IP를 반환함
  • 브라우저가 그 IP에 HTTP 요청을 보내면 애니캐스트 방식에 의해 가장 가까운 엣지 서버가 자동 선택되어 요청을 처리함


  • 애니캐스트를 사용해 엣지를 선택하는 장점은 실제 사용자와 가까운 네트워크의 엣지 서버가 선택된다는 것과 서버 장애 시 자동 우회하므로 가용성도 어느 정도 보장되는 것임
  • 하지만 애니캐스트에서 사용되는 BGP는 지리적 경로보다 ISP 정책에 따른 경로를 선택하기 떄문에 실제 사용자와 지리적으로 가장 가까운 엣지 선택을 보장하지 않음
  • 또한 BGP를 통한 경로 탐색 시 엣지 서버들의 성능 상태를 고려하지 않기 때문에 간혹 수행되지 않는 엣지 서버가 선택될 수 도 있음

퍼스트 마일 최적화

  • 라스트 마일 구간에서 최적의 엣지 서버를 찾았다면 퍼스트 마일에서는 최적의 원본 서버를 찾아야 함
  • 오직 하나의 데이터 센터를 운영하는 웹 사이트라면 퍼스트 마일 구간의 경로 최적화가 크게 효과적이지 않지만, 다수 데이터 센터를 통해 고가용성을 유지하고자 한다면 상황에 따라 적절한 데이터 센터를 찾아 사용자 요청을 전달하고 응답을 받는 것이 중요함
  • CDN 업체마다 지원 여부에 차이가 있겠지만 일반적으로 트래픽 분산은 다음과 같은 방식으로 수행됨
    • 비율에 따른 트래픽 분산
    • 지역에 따른 트래픽 분산
    • 성능에 따른 트래픽 분산


  • 데이터 센터가 선택되면 엣지 서버가 사용자 요청을 선택된 데이터 센터로 전송함
  • 사용자의 로그인 세션이 끊기지 않기 위해 한 사용자의 요청이 어떤 하나의 데이터 센터에서 처리되었다면 그 사용자의 이어지는 요청들이 모두 똑같은 데이터 센터에서 처리되어야 함
  • 이를 위해 CDN에서는 사용자 쿠키에 선택된 데이터 센터의 정보를 넣어 동일 사용자 요청들은 동일 데이터 센터로 전송되도록 함

미들 마일 최적화

  • 미들 마일 전달 경로 최적화는 사용자 요청을 받은 엣지 서버와 원본 서버 간 가장 빠른 네트워크 경로를 찾아내는 작업임
  • 일반적으로 엣지 서버는 BGP 프로토콜을 이용해 최선의 경로를 찾아냄
  • BGP가 가장 빠른 경로를 보장하지 않으며 지리적 최적 경로를 찾았다 할지라도 그 네트워크 구간에 트래픽이 몰리면 우회 경로보다 더 오랜 시간 지연을 초래하기도 함

프로토콜 최적화

  • 사용자 기기와 원본 서버 간 웹 트래픽 가속화를 위해 경로 최적화와 더불어 프로토콜 최적화가 병행되어야 함
  • 경로 최적화가 빠른 길을 찾는 과정이라면 프로토콜 최적화는 한번에 많은 트래픽을 보낼 수 있도록 길을 넓히는 작업임
  • 요청 및 응답을 빠르게 전달하려면 한번에 가능한 많은 패킷을 보내는 것이 유리함
  • 하지만 보내는 측이 많은 데이터 패킷을 보낸다 해도 받는 측이 이를 모두 수용할 수 있는 것이 아님
  • 이러한 상황을 제어하기 위해 받는 측은 윈도우 사이즈(Receivers Advertised Window Size, RWIN), 즉 수신 가능한 데이터 크기를 서버에 통지함
TCP 최적화
  • 모든 네트워크 참여자들이 무분별하게 많은 패킷들을 한번에 보내면 공용으로 써야하는 네트워크가 혼잡해져 모두에게 피해가 갈 수 있음
  • TCP는 이러한 혼잡 상황을 제어하기 위해 송신 측이 전송을 시작할 때 적은 양의 데이터부터 전송하는 느린 시작 알고리즘을 사용함
  • 이렇게 전송하는 데이터의 크기를 혼잡 윈도우라고 함


  • CDN 구간에서 TCP를 최적화하려면 먼저 미들 마일의 네트워크가 잘 관리되고 양호하다는 전제가 있어야 함
  • 이 전제하에 첫 번쨰로 초기 혼잡 윈도우 값을 늘려 한번에 많은 데이터 패킷을 보낼 수 있게 함
  • 두 번째로 RTO(재전송 타임 아웃, Resubmit Time Out) 값을 낮춰 실패한 패킷을 빠르게 재전송 함
  • 이러한 이론은 퍼스트 마일에서도 적용할 수 있으며, 퍼스트 마일에서는 데이터를 송신하는 측이 원본 서버가 됨
TLS 종료와 TCP 연결 재사용
  • HTTP 통신을 위해 클라이언트와 서버는 TCP 연결을 맺기 위한 3-way handshake와 상호 인증서를 확인하고 메시지를 암호화하기 위한 TLS handshake를 수행함
  • 모든 사용자가 CDN의 엣지 서버와 TCP/IP 연결을 생성할 때 엣지 서버가 원본 서버와 사용자 수 만큼의 연결을 새로 한 번 더 생성하는 것은 비효율적임
  • 그래서 CDN 서비스 제공자들은 효율성을 높이기 위해 원본 서버와의 TCP 연결을 바로 끊지 않고 이미 생성된 연결들을 재사용함

기타 성능 옵션

  • CDN 서비스를 사용하는 장점 중 하나는 웹 사이트 호스팅 서버에서 제공하지 못했던 기능을 CDN이 제공한다는 것임
  • 이런 기능들은 기본적이지만 관리 부서에서 적용하지 못했거나 도입이 부담스러운 신기술, 또는 적용 방법을 자체를 모르는 기능들일 수 있음

CDN이 대신 제공하는 기본 기능

  • 지금부터 설명하는 기능들은 웹 호스팅 서버에서도 쉽게 구현할 수 있지만, CDN에서도 관련 기능을 제공하므로 잘 활용하면 추가로 수고하지 않아도 해당 기능들을 아주 편리하게 사용할 수 있음
HTTP 압축
  • HTTP 압축은 웹 서버 설정을 통해 쉽게 구현할 수 있음
  • CDN 서비스를 사용 중이라면 엣지 서버는 기본적인 텍스트 파일 포맷에 gzip 압축을 적용해 브라우저로 전송함
  • 웹 사이트 호스팅 서버가 gzip 압축을 지원하지 않으면 이 기능을 아주 유용하게 사용할 수 있음
  • 웹 사이트에 사용되는 모든 텍스트 파일 형식을 확인해 CDN 압축 설정에 추가하면 더 잘 활용할 수 있음
  • CDN이 제공하는 압축은 엣지 서버와 브라우저 네트워크 구간에만 적용됨
브라우저 캐시
  • CDN 서비스를 사용하면 콘텐트 캐시 주기를 별도로 설정함
  • 따라서 서버가 CDN에 콘텐츠를 캐시하기 위해 Cache-Control: max-age나 expire 헤더를 사용할 필요가 없음
  • 그렇다고 해서 Cache-Control을 사용하지 않으면 브라우저 캐시를 사용할 수 없으므로 대부분 CDN 업체는 브라우저를 위한 Cache-Control을 어떻게 처리할 것인지 옵션을 제공함
HTML, CSS, 자바스크립트 최소화
  • 엣지 서버에서는 응답 콘텐츠에서 공백, 주석 등을 제거해 캐시한 후 같은 요청에 대해서 이미 최적화된 콘텐츠를 제공함으로써 사용자에게 응답하는 속도를 높일 수 있음
DNS 프리페치와 프리커넥트
  • <link rel="dns-prefetch"> 태그를 이용해 브라우저에 성능 개선 힌트를 줄 수 있는데, 모든 웹 페이지에 <link> 태그를 삽입하기 어렵다면 CDN에서 제공하는 DNS 프리페치 기능을 사용할 수 있음
  • 최근에는 DNS 조회와 더불어 아래 예처럼 TCP 연결까지 미리 생성하는 프리커넥트가 추가됨

신기술 적용을 위한 CDN 기능

HTTP/2와 HTTP/3
  • HTTP/2는 이미 많은 기업에서 도입해 사용 중이므로 신기술이라 하기엔 어렵지만, CDN 업계에서는 HTTP/2의 전신인 SPDY가 적용되던 시기부터 이를 빠르게 검증하고 홍보해 왔음
  • CDN 네트워크에서 HTTP/2는 대부분 브라우저와 엣지 서버 사이 구간에서만 캐시할 수 있는 정적 콘텐츠를 가속하는 데 사용함
  • 따라서 원본 서버의 HTTP/2 지원 여부와 상관없이 이를 적용하고 사용자들에게 HTTP/2의 이점을 제공할 수 있음
  • HTTP/3은 HTTP/2보다 빠르고 안전한 차세대 프로토콜로써 활발하게 표준화가 논의중임
    • 아직은 CloudFlare에서만 유일하게 지원
서버 푸시
  • HTTP/2의 주요 기능 중 하나인 서버 푸시 기능은 CDN 설정에 HTTP/2 기능을 추가해도 즉시 사용할 수 없는 조금 특별한 기능임
  • 서버 푸시는 푸시 대상을 지정하는 방식에 따라 크게 두 가지로 구분함
  • 첫 번째는 CDN에 푸시할 자원들을 미리 지정하는 방식
  • 두 번째는 웹 페이지에 푸시할 리소스를 태그로 지정하는 방식
    • 일반적으로 <link> 태그의 preload를 많이 사용함
IPv6 듀얼 스택
  • 인터넷 사용자가 급증하여 IPv4로 할당할 수 있는 IP 주소는 이미 포화 상태에 이르렀음
  • IPv4는 32비트 길이를 사용해 주소를 만들지만 IPv6는 128비트 길이를 사용하므로 약 340조 개의 고유 IP를 만들 수 있음
  • IPv6는 여러 장점이 있지만 기업 네트워크 인프라스트럭처를 전환하는 것은 간단하지 않음
  • 또한 여전히 많은 웹 사용자들이 IPv4를 사용하고 있음
  • 그러므로 CDN 서비스 제공자들은 IPv4/IPv6를 모두 사용할 수 있는 듀얼 스택을 장착해 IPv6의 장점을 미리 경험할 수 있는 기회를 제공함

💭 Insights

CDN 적용 방법

  1. 원본 서버로 사용할 호스트명과 IP를 네임 서버의 A 레코드로 추가함
  2. CDN 설정에 원본 서버의 호스트명으로 org-www.example.com을 등록함
  3. 마지막으로 기존 도메인명에 부여되어 있던 IP 정보를 CDN 서비스 제공자의 도메인명으로 변경해야 함
  • 책에서 나온 CDN 적용 방법에 대해 자세히 찾아보았다
  • 먼저 네임 서버의 레코드는 도메인 이름을 IP 주소, 다른 도메인 이름, 메일 서버 등과 연결하는 역할은 한다.
  • A 레코드는 IPv4 유형의 IP 주소와 도메인을 연결해 주는 레코드이다.
  • AAAA 레코드는 IPv6 유형의 IP 주소와 도메인을 연결해 주는 레코드이다.
  • CNAME 레코드는 다른 도메인 이름과 도메인을 연결해 주는 레코드이다.


  • 원본 서버 호스트명 org-www.example.com을 A 레코드로 원본 서버의 IP 주소 106.10.178.36과 연결하면, org-www.example.com 접근 시 106.10.178.36로 접근이 된다.
  • CDN 설정에 원본 서버의 호스트명으로 org-www.example.com를 등록하면, CDN에 접속 시 IP 주소 106.10.178.36에 접근이 될 것이다.
  • 마지막으로 CNAME 레코드로 CDN의 도메인 명인 www.example.cdn.com와 기존의 서비스 하던 도메인 명인 www.example.com을 연결한다면,
  • 최종적으로 www.example.com로 접속을 하면, CDN인 www.example.cdn.com와 연결이 되고,
  • www.example.cdn.com은 원본 서버인 org-www.example.com와 연결이 되고,
  • org-www.example.com와 연결된 106.10.178.36 서버와 연결이 될 것이다.


  • 최근에 AWS의 S3를 이용한 정적 페이지 배포를 하면서, HTTPS를 적용하기 위해 CDN 서비스인 AWS의 CloudFront를 이용한 적이 있다.
  • CloudFront 설정에 원본 서버의 호스트명으로 S3에 배포한 정적 페이지의 URL을 등록해주었다.
  • 그 다음에 가비아에서 도메인을 구입해 AWS의 Route53을 이용해 호스팅을 진행하였다.
  • 이 때 가비아에 Route53의 호스팅 영역을 생성하면서 생긴 네임서버를 연결해 주었고, Route 53에 레코드 생성을 해 주었다.
  • 레코드를 생성해 구입한 도메인과 CloudFront의 도메인 명을 연결해 주었는데 이 때 사용했던 레코드가 A 레코드였다.
  • 왜 CNAME 레코드가 아니라 A 레코드를 사용하는지 궁금해 찾아 보았다.
  • 일단 CNAME 레코드는 루트 도메인을 연결할 수 없다. example.com 형태의 도메인은 연결이 불가능하고 www.example.com 등의 도메인만 연결이 가능하다.
  • 또한 레코드 종류에는 Alias 레코드라고 있는데, 이는 A레코드와 CNAME 레코드를 합친것과 비슷한 레코드인데, 루트 도메인 연결도 가능하다고 한다.
  • AWS에서는 Alias 레코드를 사용하면, AWS 리소스와 연결이 가능해진다.
  • 레코드를 생성할 때 따로 별칭(alias) 설정을 활성화 하게 된다면, AWS 리소스와 연결이 가능해지기 때문에 AWS 리소스인 CloudFront의 도메인과 연결이 가능한 것이다.

BGP란?

  • BGP(Border Gateway Protocol)는 인터넷에서 주 경로 지정을 담당하는 프로토콜의 한 종류
  • 인터넷에서 목적지까지 경유하는 자율 시스템 중 라우팅 및 자율 시스템(AS)의 순서를 전송하기 위해 설계된 경로 지정 알고리즘으로, 표준화된 외부 게이트웨이 프로토콜의 하나이다.


  • BGP은 인터넷의 우편 서비스이다. 누군가 우체통에 편지를 투입하면 우체국에서 이 편지를 수거해서 수신자에게 전달하기 위한 빠르고 효율적인 경로를 선택한다. 마찬가지로 누군가 인터넷을 통해 데이터를 제출하면 BGP는 해당 데이터가 이동할 수 있는 가용 경로를 모두 검토하고 최적의 경로를 선택하는 일을 담당한다. 최적의 경로에는 자율 시스템 간의 호핑이 포함되는 경우가 많다.
  • 인터넷은 네트워크의 네트워크로서 자율 시스템(AS)이라고 하는 수십만 개의 작은 네트워크로 나뉘어진다. 이들 각각의 네트워크는 기본적으로 하나의 조직이 운영하는 라우터들의 큰 집합이다.

참고자료: BGP란 무엇일까요? - Cloudflare

results matching ""

    No results matching ""